谈谈 final、finally、 finalize 有什么不同

字数统计: 1.7k字   |   阅读时长: 6分
java 阅读量

典型区别

  • final 可以用来修饰类、方法、变量，分别有不同的意义，final 修饰的 class 代表不可以继承扩展，final 的变量是不可以修改的，而 final 的方法也是不可以重写的（override）。

  • finally则是 Java 保证重点代码一定要被执行的一种机制。我们可以使用 try-finally 或者 try-catch-finally 来进行类似关闭 JDBC 连接、保证 unlock 锁等动作。

  • finalize 是基础类 java.lang.Object 的一个方法，它的设计目的是保证对象在被垃圾收集前完成特定资源的回收。finalize 机制现在已经不推荐使用，并且在 JDK 9 开始被标记为 deprecated。

语法、并发、性能、生命周期等

final

  • 我们可以将方法或者类声明为 final，这样就可以明确告知别人，这些行为是不许修改的。

    如果你关注过 Java 核心类库的定义或源码， 有没有发现 java.lang 包下面的很多类，相当一部分都被声明成为 final class？在第三方类库的一些基础类中同样如此，这可以有效避免 API 使用者更改基础功能，某种程度上，这是保证平台安全的必要手段。

  • 使用 final 修饰参数或者变量，也可以清楚地避免意外赋值导致的编程错误，甚至，有人明确推荐将所有方法参数、本地变量、成员变量声明成 final。

  • final 变量产生了某种程度的 不可变（immutable） 的效果，所以，可以用于保护只读数据，尤其是在并发编程中，因为明确地不能再赋值 final 变量，有利于减少额外的同步开销，也可以省去一些防御性拷贝的必要。

    final 也许会有性能的好处，比如，利用 final 可能有助于 JVM 将方法进行内联，可以改善编译器进行条件编译的能力等等。坦白说，很多类似的结论都是基于假设得出的，比如现代高性能 JVM（如 HotSpot）判断内联未必依赖 final 的提示，要相信 JVM 还是非常智能的。

对于final的不可变（immutable）做个说明

1
2
3
4
5
final List<String> strList = new ArrayList<>();
strList.add("Hello");
strList.add("world");  
List<String> unmodifiableStrList = List.of("hello", "world");
unmodifiableStrList.add("again");

final 只能约束 strList 这个引用不可以被赋值，但是 strList 对象行为不被 final 影响，添加元素等操作是完全正常的。如果我们真的希望对象本身是不可变的，那么需要相应的类支持不可变的行为。在上面这个例子中，List.of 方法创建的本身就是不可变 List，最后那句 add 是会在运行时抛出异常的。

  • 还有一个地方值得说明，当 内部类 (inner clas) 访问局部变量的时候，是需要用final声明变量的，因为Java inner class实际会copy一份，不是去直接使用局部变量，final可以防止出现数据一致性问题。

finally

虽然说正常情况下finally是可以保证重点代码一定要被执行的一种机制，但他也有不执行的时候：

  1. 程序退出

    1
    2
    3
    4
    5
    6
    7
    8
    9
    @Test
        public void client() throws Exception{
            try {
                // do something
                System.exit(1);
            } finally{
                System.out.println("Print from finally");
            }
        }
    • system.exit（0） : 正常退出，程序正常执行结束退出
    • system.exit （1） : 是非正常退出，就是说无论程序正在执行与否，都退出

  2. 无限循环

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    @Test
        public void client() throws Exception{
            try {
                // do something
                while (true){
                    System.out.println("loop");
                }
            } finally{
                System.out.println("Print from finally");
            }
        }

  3. 线程被杀死

    • 当执行 try，finally 的线程被杀死时。finally 也无法执行。
  • 所以 不要在 finally 中使用 return 语句。finally 总是执行，除非程序或者线程被中断。

finalize

  • 对于 finalize，我们要明确它是不推荐使用的，业界实践一再证明它不是个好的办法，在 Java 9 中，甚至明确将 Object.finalize()标记为 deprecated ！如果没有特别的原因，不要实现 finalize方法，也不要指望利用它来进行资源回收。

为什么呢？简单说，你无法保证 finalize 什么时候执行，执行的是否符合预期。使用不当会影响性能，导致程序死锁、挂起等。

通常来说，利用上面的提到的 try-with-resources 或者 try-finally 机制，是非常好的 回收资源的办法。如果确实需要额外处理，可以考虑 Java 提供的 Cleaner 机制 或者其他替代方法。

  • finalize 的执行是和垃圾收集关联在一起的，一旦实现了非空的 finalize 方法，就会导致相应对象回收呈现数量级上的变慢，有人专门做过 benchmark，大概是 40~50 倍的下降。
  • 因为，finalize 被设计成在对象被垃圾收集前调用，这就意味着实现了 finalize 方法的对象是个“特殊公民”，JVM 要对它进行额外处理。finalize 本质上成为了快速回收的阻碍者，可能导致你的对象经过多个垃圾收集周期才能被回收。

有人也许会问，我用 System.runFinalization() 告诉 JVM 积极一点，是不是就可以了？也许有点用，但是问题在于，这还是不可预测、不能保证的，所以本质上还是不能指望。实践中，因为 finalize 拖慢垃圾收集，导致大量对象堆积，也是一种典型的导致 OOM (OutOfMemoryError ) 的原因。

从另一个角度，我们要确保回收资源就是因为资源都是有限的，垃圾收集时间的不可预测，可能会极大加剧资源占用。这意味着对于消耗非常高频的资源，千万不要指望 finalize 去承担资源释放的主要职责，最多让 finalize 作为最后的“守门员”，况且它已经暴露了如此多的问题。推荐是：资源用完即显式释放，或者利用资源池来尽量重用。

finalize 还会掩盖资源回收时的出错信息，我们看下面一段 JDK 的源代码，截取自 java.lang.ref.Finalizer

1
2
3
4
5
6
7
8
9
10
11
12
13
private void runFinalizer(JavaLangAccess jla) {
//  ... 省略部分代码
try {
   Object finalizee = this.get(); 
   if (finalizee != null && !(finalizee instanceof java.lang.Enum)) {
      jla.invokeFinalize(finalizee);
      // Clear stack slot containing this variable, to decrease
      // the chances of false retention with a conservative GC
      finalizee = null;
   }
 } catch (Throwable x) { }
   super.clear(); 
}

这里的Throwable 是被生吞了的！也就意味着一旦出现异常或者出错，你得不到任何有效信息。况且，Java 在 finalize 阶段也没有好的方式处理任何信息，不然更加不可预测。

Copyright © 2018 - 2020 Kuanger All Rights Reserved.

访客数 : | 访问量 :